Many organizations choose to implement AD RMS in stages.
The first stage
focuses on internal use of intellectual property. In this stage, you
concentrate on implementing proper access rights for the documentation
you produce. Employees can view, read, and manage only content they are
involved with. Content cannot be copied except under strict conditions.
The
second stage involves sharing content with partners. Here you begin to
provide protected content to partner firms. Partners can view and access
protected documents but cannot copy or otherwise share the information.
The
third stage involves a wider audience. Your intellectual property can
be distributed outside the boundaries of your network in a protected
mode. Because it is protected, it cannot be copied or distributed
electronically unless you give the required authorizations.
In each case, you must be sure
to communicate your document protection policy fully to the people who
will be working with your data. Employees must be fully trained on the
AD RMS solution to understand the impact of divulging information to
unauthorized audiences. Partners should be provided with policy
statements so they can understand how to protect your information. Then,
when you reach wider audiences, you must make sure that they also fully
understand your protection policies so they can work with your
information properly.
Each stage of the implementation requires additional components to further the reach of your protection strategies.
1. Understanding AD RMS
AD RMS
is an updated version of the Rights Management Services available in
Microsoft Windows Server 2003. With the latest release, Microsoft has
included several new features that extend the functionality included in
AD RMS. However, the scenarios you use to deploy AD RMS remain the same.
AD RMS works with a special AD
RMS client to protect sensitive information. Protection is provided
through the AD RMS server role, which is designed to provide certificate
and licensing management. Information—configuration and logging—is
persisted in a database. In test environments, you can rely on the
Windows Internal Database (WID) included in Windows Server 2008 R2, but
in production environments, you should rely on a formal database engine
such as Microsoft SQL Server 2005 or Microsoft SQL Server 2008 running
on a separate server. This provides the ability to load balance AD RMS
through the installation of multiple servers running this role. WID does
not support remote connections; therefore, only one server can use it.
Internet Information Services (IIS) 7.0 provides the web services upon
which AD RMS relies, and the Microsoft Message Queuing service ensures
transaction coordination in distributed environments. The AD RMS client
provides access to AD RMS features on the desktop. In addition, an AD DS
directory provides integrated authentication and administration. AD RMS
relies on AD DS to authenticate users and verify that they are allowed
to use the service. This makes up the AD RMS infrastructure, shown in Figure 1.
The first time you install
an AD RMS server, you create an AD RMS root cluster by default. A root
cluster is designed to handle both certification and licensing requests.
Only one root cluster can exist in an AD DS forest. You can also
install licensing-only servers, which automatically form a licensing
cluster. Clusters are available only if you deploy the AD RMS database
on a separate server. Each time you add a new AD RMS server with either
the root or the licensing role, it is automatically integrated into the
corresponding existing cluster. Microsoft recommends that you rely on
the root role more than the licensing-only role for two reasons:
Root clusters handle all AD RMS operations and are, therefore, multifunctional.
Root
and licensing-only clusters are independent; that is, they cannot share
load balancing of the service. If you install all your servers as root
servers, they automatically load balance each other.
After the
infrastructure is in place, you can enable information-producing
applications such as word processors, presentation tools, email clients,
and custom in-house applications to rely on AD RMS to provide
information protection services. As users create information, they
define who can read, write, modify, print, transfer, and otherwise
electronically manipulate the information. In addition, you can create
policy templates that can apply a given configuration to documents as
they are created.
Tip:
EXAM TIP
Remember that any server
installation in AD RMS automatically creates a cluster. This cluster
should not be confused with the Failover Clustering or Network Load
Balancing services that are included in Windows Server 2008 R2. The AD
RMS cluster is designed to provide high availability and load balancing
to ensure that the service is always available.
Usage rights are
embedded directly within the documents you create so that the
information remains protected even if it moves beyond your zone of
authority. For example, if a protected document leaves your premises and
arrives outside your network, it will remain protected because AD RMS
settings are persistent. AD RMS offers a set of web services that allow
you to extend AD RMS and integrate its features
in your own information-producing applications. Because they are web
services, organizations can use them to integrate AD RMS features even
in non-Windows environments.
Note:
MORE INFO AD RMS
Find out more about AD RMS at http://go.microsoft.com/fwlink/?LinkId=80907.
1.1. AD RMS Features
Active Directory Rights Management Services includes several new features:
AD RMS is now a server
role that is integrated into Windows Server 2008 R2. In previous
releases, the features supported by AD RMS were in a package that
required a separate download. In addition, the Server Manager
installation provides all dependencies and required component
installations. Also, if no remote database is indicated during
installation, Server Manager automatically installs Windows Internal
Database.
As with most of the Windows Server 2008 R2 server roles, AD
RMS is administered through a Microsoft Management Console (MMC).
Previous versions provided administration only through a web interface.
AD
RMS includes direct integration with Active Directory Federation
Services, allowing you to extend your rights management policies beyond
the firewall with your partners. This means that your partners do not
need their own AD RMS infrastructures and can rely on yours through AD
FS to access AD RMS features.
In previous releases, you could rely on only Windows Live IDs to
federate RMS services. With the integration of AD RMS and AD FS, you no
longer need to rely on a third party to protect information. However, to
use federation, you must have an established federated trust before you
install the AD RMS extension that integrates with AD FS, and you must
use the latest RMS client—the Windows 7 client or the RMS client with
SP2 for versions of Windows earlier than Windows 7.
AD RMS servers are self-enrolled when they are created. Enrollment creates a server
licensor certificate (SLC), which grants the server the right to
participate in the AD RMS structure. Earlier versions required access to
the Microsoft Enrollment Center through the Internet to issue and sign
the SLC. AD RMS relies
on a self-enrollment certificate that is included in Windows Server 2008
R2. Because of this, you can now run AD RMS in isolated networks
without requiring Internet access of any kind.
Finally,
AD RMS includes administration roles so that you can delegate specific
AD RMS tasks without having to grant excessive administration rights.
Four local administrative roles are created:
AD
RMS Enterprise Administrators, which can manage all aspects of AD RMS.
This group includes the user account used to install the role as well as
the local administrators group.
AD
RMS Template Administrators, which supports the ability to read
information about the AD RMS infrastructure as well as list, create,
modify, and export rights policy templates.
AD
RMS Auditors, which allows members to manage logs and reports. Auditors
have read-only access to AD RMS infrastructure information.
AD RMS Service, which contains the AD RMS service account that is identified during the role installation.
Because
each of these groups is local, create corresponding global groups in
your AD DS directory and insert these groups within the local groups on
each AD RMS server.
Then, when you need to grant rights to an administrative role, all you
need to do is add the user’s account to the global groups in AD DS.
Tip:
Delegation is an important
aspect of AD RMS administration. Pay close attention to the various
delegation roles and the groups that support them.
Note:
MORE INFO FEATURES AVAILABLE IN PREVIOUS RELEASES
For information on features released in RMS before Windows Server 2008 R2, go to http://go.microsoft.com/fwlink/?LinkId=68637.
Basically, when you protect information through AD RMS, you rely on the AD RMS server to issue rights
account certificates. These certificates identify the trusted
entities—users, groups, computers, applications, or services—that can
create and publish rights-enabled content. After a content publisher has
been trusted, it can assign rights and conditions to the content it
creates. Each time a user establishes a protection policy on a document,
AD RMS issues a publishing
license for the content. By integrating this license in the content, AD
RMS binds it so that the license becomes permanently attached and no
longer requires access to an AD RMS system to provide document or
content protection.
Usage rights are
integrated in any form of binary data that supports usage within or
outside your network, as well as online or offline. When content is
protected, it is encrypted with special encryption keys, much like the
keys created when using AD CS. To view the data, users must access it
through an AD RMS–enabled browser or application. If the application is
not AD RMS enabled, users cannot manipulate the information because the
application cannot read the protection policy to decrypt the data
properly.
When other users access the
rights-protected content, their AD RMS clients request a usage license
from the server. If the user is also a trusted entity, the AD RMS server
issues this use license. The use license reads the protection license
for this document and applies these usage rights to the document for the
duration of its lifetime.
To facilitate the
publishing process, trusted users can create protection licenses from
predefined templates that can be applied with the tools they are already
familiar with, such as word processors and email clients. Each template
applies a specific predefined usage policy, as shown in Figure 2.
1.2. AD RMS Installation Scenarios
Each organization has its own
needs and requirements for information protection. For this reason, AD
RMS supports several deployment scenarios. These scenarios include:
Single-server deployment
Install AD RMS on a single server. This installs the WID as the support
database. Because all the components are local, you cannot scale this
deployment to support high availability. Use the single-server
deployment only in test environments. If you want to use this deployment
to test AD RMS beyond the firewall, you must add appropriate AD RMS
exceptions.
Internal deployment
Install AD RMS on multiple servers tied to an AD DS directory. You must
use a separate server to host the AD RMS database; otherwise, you will
not be able to load balance the AD RMS role.
Extranet deployment
When users are mobile and do not remain within the confines of your
network, you must deploy AD RMS in an extranet—a special perimeter
network that provides internal services to authorized users. In this
scenario, you must configure appropriate firewall exceptions and add a
special extranet URL on an external-facing web server to allow external
client connections.
Note:
MORE INFO AD RMS CONFIGURATION IN AN EXTRANET
For more information on how to configure AD RMS to collaborate outside of the organizational network, see the “AD RMS Deployment in an Extranet Step-by-Step Guide” at http://technet.microsoft.com/en-us/library/cc753490(WS.10).aspx.
Multiforest deployment
When you have existing partnerships that are based on AD DS forest
trusts, you must perform a multiforest deployment. In this case, you
must deploy multiple AD RMS installations, one in each forest. Then,
assign a Secure Sockets Layer (SSL) certificate to each website that
hosts the AD RMS clusters in each forest. You must also extend the AD DS
forest schema to include AD RMS objects. However, if you are using
Microsoft Exchange Server in each forest, the extensions will already
exist. Finally, your AD RMS service account—the account that runs the
service—will need to be trusted in each forest.
Note:
MORE INFO MULTIFOREST AD RMS DEPLOYMENTS
For more information on this deployment model, see http://technet.microsoft.com/en-us/library/cc772182(WS.10).aspx.
AD RMS with AD FS deployment
You can also extend the AD RMS root cluster to other forests through
Active Directory Federation Services. To do so, you must prepare the
following:
Assign an
SSL certificate to the website hosting the AD RMS root cluster. This
ensures secure communications between the cluster and the AD FS resource
server.
Install the root cluster.
Prepare a federated trust relationship before you install the Identity Federation Support role service of AD RMS.
Create a claims-aware application on the AD FS resource partner server for both the certification and the licensing pipelines of AD RMS.
Assign the Generate Security Audits user right to the AD RMS service account.
Define
the extranet cluster URL in AD RMS, and then install the AD RMS
Identity Federation Support role service through Server Manager. Have
the federation URL available during installation.
Note:
MORE INFO AD RMS AND AD FS DEPLOYMENT
For more information on the AD RMS and AD FS deployment, see http://technet.microsoft.com/en-us/library/cc771425(WS.10).aspx.
Licensing-only server deployment In complex forest environments, you might want to deploy a licensing-only AD
RMS cluster in addition to the root cluster. In this case, you must
first assign an SSL certificate to the website hosting the AD RMS root cluster and then install the root cluster. After you meet these conditions, you can install licensing-only servers.
Note:
MORE INFO SET UP A LICENSING-ONLY AD RMS CLUSTER
For more information on how to set up a licensing-only AD RMS cluster, see http://technet.microsoft.com/en-us/library/cc730671(WS.10).aspx.
Upgrade Windows RMS to AD RMS If you upgrade from an existing Windows RMS installation, you must perform the following activities:
Make sure your RMS systems are upgraded to RMS Service Pack 1 prior to the upgrade.
Back up all servers, and back up the configuration database. Store it in a secure location.
If
you are using offline enrollment to set up your Windows RMS
environment, make sure the enrollment is complete before the upgrade.
If
you already have service connection points in Active Directory
directory service, make sure you use the same URL for the upgrade.
If
your Windows RMS database is running Microsoft SQL Server Desktop
Engine (MSDE), you must upgrade to SQL Server before you upgrade to AD
RMS.
Clear the RMS Message Queuing queue to make sure all messages are written to the RMS logging database prior to upgrade.
Upgrade the root cluster before upgrading the licensing-only server. This provides the root cluster’s self-signed SLC to the licensing server when you upgrade it.
Upgrade all other servers in the RMS cluster.
These scenarios provide the most common deployment structures for AD RMS.
